Control method, data structure, server, and recording medium

ABSTRACT

A control method includes: receiving first transaction data related to a sign-up for service and storing the first transaction data received into the distributed ledger included in each of the plurality of servers, the service offering, if a goal condition predetermined for the service is satisfied, a token to a participant that is a user who signs up for the service; storing, into the distributed ledger, second transaction data indicating that the user is offered the token predetermined for the service, if it is determined that the goal condition is satisfied; and storing, into the distributed ledger, third transaction data indicating that the user is offered a deposit that is a temporary token predetermined for the service, at a predetermined timing included in a period from the storing of the first transaction data into the distributed ledger until when determination of whether the goal condition is satisfied is performed.

CROSS REFERENCE TO RELATED APPLICATIONS

This is a continuation application of PCT International Application No.PCT/JP2020/004679 filed on Feb. 6, 2020, designating the United Statesof America, which is based on and claims priority of U.S. ProvisionalPatent Application No. 62/802,861 filed on Feb. 8, 2019. The entiredisclosures of the above-identified applications, including thespecifications, drawings and claims are incorporated herein by referencein their entirety.

FIELD

The present disclosure relates to a control method, a data structure, aserver, and a recording medium.

BACKGROUND

A system has been developed for providing one who achieves apredetermined condition with value information like a virtual currencyin exchange for the achievement (see Patent Literature [PTL] 1).

CITATION LIST Patent Literature

PTL 1: Japanese Unexamined Patent Application Publication No.2018-136729

SUMMARY Technical Problem

However, the aforementioned system does not provide a user with thevalue information before the predetermined condition is achieved. Thisleads to poor operating efficiency of the system, unfortunately. Morespecifically, although the system consumes power even in a period beforethe predetermined condition is achieved, the value information is notprovided to the user in this period. Thus, power consumption efficiencyof the system is low.

In response to this issue, the present disclosure provides a controlmethod, and so on, that are capable of enhancing power consumptionefficiency of a system.

Solution to Problem

A control method according to an aspect of the present disclosure is acontrol method executed by one of a plurality of servers included in aservice management system, each of the plurality of servers including adistributed ledger, the control method including: receiving firsttransaction data that is transaction data related to a sign-up forservice and storing the first transaction data received into thedistributed ledger included in each of the plurality of servers, theservice offering, if a goal condition predetermined for the service issatisfied, a token to a participant that is a user who signs up for theservice; storing, into the distributed ledger, second transaction datathat is transaction data indicating that the user is offered the tokenpredetermined for the service, if it is determined that the goalcondition is satisfied; and storing, into the distributed ledger, thirdtransaction data that is transaction data indicating that the user isoffered a deposit that is a temporary token predetermined for theservice, at a predetermined timing included in a period from the storingof the first transaction data into the distributed ledger until whendetermination of whether the goal condition is satisfied is performed.

Note that these general and specific aspects may be implemented as asystem, a device, an integrated circuit, a computer program, or acomputer-readable recording medium such as a CD-ROM, or as anycombination of a system, a device, an integrated circuit, a computerprogram, and a recording medium.

Advantageous Effects

The control method according to the present disclosure can enhance powerconsumption efficiency of a system.

BRIEF DESCRIPTION OF DRAWINGS

These and other advantages and features will become apparent from thefollowing description thereof taken in conjunction with the accompanyingDrawings, by way of non-limiting examples of embodiments disclosedherein.

FIG. 1 is a schematic block diagram of a system according to anembodiment.

FIG. 2 is a schematic block diagram of a server according to theembodiment.

FIG. 3 schematically illustrates deposit issuance transaction dataaccording to the embodiment.

FIG. 4 schematically illustrates deposit offering transaction dataaccording to the embodiment.

FIG. 5 schematically illustrates deposit invalidation transaction dataaccording to the embodiment.

FIG. 6 schematically illustrates token offering transaction dataaccording to the embodiment.

FIG. 7 is a flowchart illustrating a first example of processingperformed by the server according to the embodiment.

FIG. 8 is a flowchart illustrating a second example of processingperformed by the server according to the embodiment.

FIG. 9 is a sequence that corresponds to FIG. 7 and illustratessystem-wide processing.

FIG. 10 is a schematic block diagram of a system according to Variation1 of the Embodiment.

FIG. 11 is a schematic block diagram of a system according to Variation2 of the Embodiment.

FIG. 12 is a flowchart illustrating processing performed by a serveraccording to Variation 3 of the Embodiment.

FIG. 13 is a schematic block diagram illustrating a configuration of theserver according to Variation 3 of the Embodiment.

FIG. 14 illustrates a data structure of a blockchain.

FIG. 15 illustrates a data structure of transaction data.

DESCRIPTION OF EMBODIMENT (Underlying Knowledge Forming Basis of thePresent Disclosure)

In relation to the technology of the system disclosed in the Backgroundsection, the inventors have found the following problem.

A conventional system offers value information like a virtual currencyif a predetermined condition is achieved. Examples of such systeminclude crowdfunding.

Crowdfunding is a way of raising money for an investment or the likefrom participants via the Internet for instance, and then offeringmonetary returns on the investment to the participants.

However, the aforementioned system does not provide a user with thevalue information before the predetermined condition is achieved. Thisleads to poor operating efficiency of the system, unfortunately. Morespecifically, although the system consumes power even in a period beforethe predetermined condition is achieved, the value information is notprovided to the user in this period. Thus, power consumption efficiencyof the system is low.

In view of this, the present disclosure provides a control method, andso on, that are capable of enhancing the power consumption efficiency ofthe system.

A control method according to an aspect of the present disclosure is acontrol method executed by one of a plurality of servers included in aservice management system and each including a distributed ledger. Thecontrol method includes: receiving first transaction data that istransaction data related to a sign-up for service and storing the firsttransaction data received into the distributed ledger included in eachof the plurality of servers, the service offering, if a goal conditionpredetermined for the service is satisfied, a token to a participantthat is a user who signs up for the service; storing, into thedistributed ledger, second transaction data that is transaction dataindicating that the user is offered the token predetermined for theservice, if it is determined that the goal condition is satisfied; andstoring, into the distributed ledger, third transaction data that istransaction data indicating that the user is offered a deposit that is atemporary token predetermined for the service, at a predetermined timingincluded in a period from the storing of the first transaction data intothe distributed ledger until when determination of whether the goalcondition is satisfied is performed.

According to the above aspect, the system offers, to the user, thedeposit as the temporary token corresponding to a token that is valueinformation to be offered in the future, in a period before the goalcondition is achieved. The deposit may be managed in the distributedledger to be used in the same or similar manner as the token is. Thisenables the system to offer the value information to the user in theperiod before the goal condition is achieved, thereby enhancing powerconsumption efficiency of the system. Thus, the control method accordingto the present disclosure is capable of enhancing the power consumptionefficiency of the system.

Moreover, it is substantially impossible for the transaction data storedin the distributed ledger to be falsified. Thus, the managementinformation related to the deposit offering is appropriately managed bythe system. If the management information were to be falsified, this maycause inappropriate distribution of the value information, such asdeposit or token. However, the control method according to the aspect ofthe present disclosure stores the management information into thedistributed ledger, so that falsification is substantially impossible.Hence, the control method according to the aspect of the presentdisclosure also has an advantageous effect of appropriately managing thedistribution of the value information, such as deposit or token.

For example, the control method may further include, after the storingof the third transaction data into the distributed ledger, storing, intothe distributed ledger, fourth transaction data that is transaction dataindicating that the deposit is offered from a holder of the deposit toan offer recipient that receives the deposit.

According to the above aspect, the system is further capable of offeringthe deposit to the offer recipient and thereby distributing among usersthe value information offered to the participant. Such distribution ofthe value information enables the system to further enhance the powerconsumption efficiency. Hence, the control method according to theaspect of the present disclosure is capable of further enhancing thepower consumption efficiency of the system.

For example, the control method may further include, if it is determinedthat the goal condition is satisfied or if it is determined that thegoal condition is unsatisfied, after the storing of the thirdtransaction data into the distributed ledger, storing, into thedistributed ledger, fifth transaction data that is transaction data forinvalidating the deposit.

According to the above aspect, the system is capable of invalidating thedeposit if the goal condition is unsatisfied, and thereby appropriatelycontrolling the validity of the deposit. Hence, the control methodaccording to the present disclosure is capable of appropriately managingthe distribution of the value information as well as further enhancingthe power consumption efficiency of the system.

For example, the control method may further include, if it is determinedthat the goal condition is satisfied after the storing of the thirdtransaction data into the distributed ledger, storing, into thedistributed ledger, sixth transaction data that is transaction data foroffering a token corresponding to the deposit to a holder of thedeposit.

According to the above aspect, the system is capable of offering thetoken corresponding to the deposit if the goal condition is satisfied,and thus also performing management so that the deposit is convertedinto the token after the goal condition is satisfied. Hence, the controlmethod according to the present disclosure is capable of furtherappropriately managing the distribution of the value information as wellas further enhancing the power consumption efficiency of the system.

For example, the control method may further include, if it is determinedthat the goal condition is satisfied after the storing of the thirdtransaction data into the distributed ledger, notifying a holder of thedeposit that the goal condition is satisfied.

According to the above aspect, the system is capable of providing anotification that the goal condition is satisfied, and therebyencouraging action (that is, exchange) for converting the deposit intothe token after the goal condition is satisfied. Hence, the controlmethod according to the present disclosure is capable of furtherappropriately managing the distribution of the value information as wellas further enhancing the power consumption efficiency of the system.

For example, the control method may further include, if a holder of thedeposit is not the participant and it is determined that the goalcondition is unsatisfied after the storing of the third transaction datainto the distributed ledger, storing, into the distributed ledger,seventh transaction data that is transaction data for offering a tokencorresponding to the deposit from the participant to the holder.

According to the above aspect, the system is capable of performing, ifthe goal condition is satisfied, management so that the token convertedfrom the deposit owned by the holder different from the participantappears to be offered from the participant. If the deposit held by theholder were to simply disappear, this may cause inappropriatedistribution of the value information. Hence, the control methodaccording to the present disclosure is capable of further appropriatelymanaging the distribution of the value information as well as furtherenhancing the power consumption efficiency of the system.

For example, the storing of the fourth transaction data into thedistributed ledger may include limiting the storing of the fourthtransaction data into the distributed ledger if a total number of timesthe deposit is offered exceeds a predetermined total number of times.

According to the above aspect, the system is capable of performingmanagement so that the number of times the deposit is offered does notexceed the predetermined number of times. This management limits a rangeof the deposit offering because the deposit is allowed to be used as atoken only in a period before the goal condition is satisfied. Hence,the control method according to the present disclosure is capable offurther appropriately managing the distribution of the value informationas well as further enhancing the power consumption efficiency of thesystem.

For example, the storing of the third transaction data into thedistributed ledger may include storing of the third transaction datainto the distributed ledger through a smart contract that is executed inresponse to the storing of the first transaction data into thedistributed ledger.

According to the above aspect, the system performs the deposit offeringearly and safely without any intervention of another person or anothersystem. Hence, the control method according to the present disclosure iscapable of performing the processing early and safely as well asenhancing the power consumption efficiency of the system.

For example, the storing of the transaction data into the distributedledger included in each of the plurality of servers includes storing thetransaction data into the distributed ledger through execution of aconsensus algorithm by each of the plurality of servers.

According to the above aspect, the system stores the distributed ledgerthrough the execution of the consensus algorithm. Hence, the controlmethod according to the present disclosure more easily enablesenhancement of the power consumption efficiency of the system by theexecution of the consensus algorithm.

Furthermore, a data structure according to an aspect of the presentdisclosure is a data structure used by a service management systemincluding a plurality of servers each of which includes a distributedledger. The data structure includes: identification information thatuniquely identifies a deposit that is a temporary token predeterminedfor service; identification information that uniquely identifies anoffer recipient that receives the deposit; information that indicates anamount of the deposit; and an electronic signature of an issuer of thedeposit.

According to the above aspect, the same advantageous effect as in theabove service management system can be produced.

Furthermore, a server according to an aspect of the present disclosureis a server among a plurality of servers included in a servicemanagement system and each including a distributed ledger. The serverincludes: a processor; and a controller. The processor receives firsttransaction data related to a sign-up for service and stores the firsttransaction data received into the distributed ledger included in eachof the plurality of servers. The service offers, if a goal conditionpredetermined for the service is satisfied, a token to a participantthat is a user who signs up for the service. The controller: stores,into the distributed ledger, second transaction data indicating that theuser is offered the token predetermined for the service, if determiningthat the goal condition is satisfied; and stores, into the distributedledger, third transaction data indicating that the user is offered adeposit that is a temporary token predetermined for the service, at apredetermined timing included in a period from when storing the firsttransaction data into the distributed ledger until when determiningwhether the goal condition is satisfied.

According to the above aspect, the same advantageous effect as in theabove control method can be produced.

Furthermore, a recording medium according to an aspect of the presentinvention is a non-transitory computer-readable recording medium havingrecorded thereon a program for causing a computer to execute theabove-described control method.

According to the above aspect, the same advantageous effect as in theabove control method can be produced.

Furthermore, a data structure according to another aspect of the presentdisclosure is a data structure that is recorded into a distributedledger included in each of a plurality of servers in a servicemanagement system. The data structure includes: a first ID that is validonly in a period predetermined for service and that indicates a depositas a temporary token offered to a participant that signs up for theservice; an amount of the deposit; a use condition of the deposit; and asecond ID that indicates the participant. After being recorded into thedistributed ledger, the data structure is used for offering the depositto the participant.

According to the above aspect, the same advantageous effect as in theabove service management system can be produced.

Note that these general and specific aspects may be implemented as asystem, a device, an integrated circuit, a computer program, or acomputer-readable recording medium such as a CD-ROM, or as anycombination of a system, a device, an integrated circuit, a computerprogram, and a recording medium.

Exemplary embodiments will be described in detail below with referenceto the drawings.

Note that each of the embodiments described below shows a generic orspecific example. The numerical values, shapes, materials, structuralcomponents, the arrangement and connection of the structural components,steps, the processing order of the steps, etc., shown in the followingembodiments are mere examples, and thus are not intended to limit thepresent disclosure. Among the structural components described in thefollowing embodiments, structural components not recited in any one ofthe independent claims that indicate the broadest concepts will bedescribed as optional structural components.

EMBODIMENT

The present embodiment describes a system and a control method used bythe system that are capable of enhancing power consumption efficiency ofthe system.

This system provides service to a participant. The service offers, if agoal condition predetermined for this service is satisfied, valueinformation to the participant, namely, a user who signs up for thisservice. In the present embodiment, a token is described as an exampleof the value information. Examples of such service include crowdfunding,which is described as an example in the present embodiment. However, theservice may be a financial product, such as deposit, insurance, orinvestment.

A unit of funding for crowdfunding is also referred to as a project. Aproject is assumed to raise money for an investment or the like fromparticipants and then offer monetary returns on the investment to theparticipants. The following describes a project where: one who managesthe project is referred to as a manager; and one who signs up toparticipate in the funding is referred to as a participant. The managersolicits for funding, and manages value information. If sign-ups for thefunding meet a predetermined goal amount during a solicitation periodpredetermined for the project, this project is phrased as achieving“success” or being “successful”.

FIG. 1 is a schematic block diagram illustrating a configuration ofsystem 1 according to the present embodiment.

As illustrated in FIG. 1, system 1 includes servers 10A, 10B, and 10Cand terminals 40, 50, and 51. These devices included in system 1 arecommunicably connected to each other via network N. Network N may useany kind of communication line or network. Examples include the Internetand a mobile phone carrier network. Servers 10A, 10B, and 10C may alsoreferred to as “servers 10A etc.”

Server 10A is one of a plurality of servers 10A, 10B, and 10C thatmanage crowdfunding performed by system 1. Server 10A is one of theplurality of servers 10A, 10B, and 10C each of which holds a distributedledger. The distributed ledger held by server 10A stores various kindsof transaction data relating to procedures or processing forcrowdfunding. By receiving the transaction data, server 10A receives theprocedure or processing related to deposits and tokens for thecrowdfunding.

Note that the funding for the project is managed as token offering inthe distributed ledger, as an example. A token refers to valueinformation managed in the distributed ledger. A token corresponds to,or is exchangeable with, money, a gift certificate, or a coupon, forinstance.

A deposit refers to a temporary token and is usable until a token (alsoreferred to as a true token) is offered in response to satisfaction ofthe goal condition. More specifically, an issued deposit is managed tobe valid until a token is offered and then be invalid after the token isoffered. The deposit may refer to value information that is temporarilydeposited with the user by system 1.

Each of servers 10B and 10C has the same function as server 10A andoperates independently of server 10A. The number of servers is notlimited to three and may be at least two. Servers 10A etc. arecommunicably connected to each other, and may be connected via networkN.

The present embodiment describes a case where server 10A, out of servers10A etc., receives transaction data from terminal 40 for example andtransmits a notification to terminal 40 for example. However, the otherserver (server 10B or 10C) may perform these operations instead.

Terminal 40 is a terminal device owned by the manager. The managerdetermines a solicitation period of a project and a goal amount of theproject. The manager enters the determined solicitation period and goalamount in system 1 via terminal 40. Then, the manager solicits forfunding from participants so that a total amount achieved by sign-upsfor the funding from the participants reaches the goal amount. Terminal40 is a personal computer, a smartphone, or a tablet, for example.

Terminal 50 is a terminal device owned by a participant. The participantuses terminal 50 to sign up for the funding by reference to informationabout funding solicitation. The participant is offered a deposit beforethe project achieves success. The deposit offered may be offered toanother person from the participant. One who holds the deposit (i.e., aholder) is offered a token if the project is successful. The participantmay offer a fund to the manager when signing up for the funding.

Terminal 51 is a terminal device owned by a participant who signs up forthe funding but is different from the participant owning terminal 50.Terminal 51 has the same function as terminal 50 and operatesindependently of terminal 50. Note that the number of terminals owned bythe participants is not limited to two and that the number of terminalsis equal to the number of participants.

The following describes in details configurations of servers 10A, etc.,included in system 1.

FIG. 2 is a schematic block diagram illustrating a configuration ofserver 10A according to the present embodiment.

As illustrated in FIG. 2, server 10A includes processor 11, ledgermanager 12, and controller 13. These functional components included inserver 10A may be implemented by a central processing unit (CPU)executing a program using a memory, for example.

Processor 11 manages various kinds of information using the distributedledger. If receiving the transaction data from a device included insystem 1 or if obtaining the transaction data generated by controller13, processor 11 stores the received or obtained transaction data intothe distributed ledger by providing this transaction data to ledgermanager 12. The transaction data includes deposit issuance transactiondata, deposit offering transaction data, deposit invalidationtransaction data, and token offering transaction data. These pieces oftransaction data are described in detail below.

Ledger manager 12 is a processor that manages the distributed ledger.Ledger manager 12 stores the transaction data provided by processor 11into the distributed ledger. The distributed ledger stores thetransaction data from past to present. Information recorded in adistributed ledger has characteristics of being less subject tofalsification. This allows the aforementioned transaction data to bemanaged to avoid falsification.

Ledger manager 12 includes storage 15 and ledger memory 16.

Storage 15 is a processor that stores new transaction data, which is tobe stored into the distributed ledger, into ledger memory 16. Storage 15stores the new transaction data into ledger memory 16 according to analgorithm depending on a type of the distributed ledger. Moreover,storage 15 transmits and receives communication data to and from storage15 of a different server among servers 10A etc. and stores theaforementioned new transaction data into ledger memory 16 of thisdifferent server as well. For example, if the distributed ledger is ablockchain, storage 15 generates a block including the new transactiondata. Then, after achieving synchronization of the generated block amongservers 10A, etc., storage 15 stores this block into ledger memory 16.

Ledger memory 16 is a memory device that stores the distributed ledger.The distributed ledger stored in ledger memory 16 stores at least onepiece of transaction data, and is managed to be less subject tofalsification by taking advantage of characteristics of a hash value forexample (described below).

The distributed ledger is a blockchain for example, and the presentembodiment describes such a case. However, a distributed ledger based ona different algorithm (such as IOTA or hashgraph) may be adopted. Notethat the distributed ledger may or may not execute a consensus algorithm(such as Practical Byzantine Fault Tolerance [PBFT], Proof of Work[PoW], or Proof of Stake [PoS]) to store new data. Examples ofdistributed ledger technology that executes no consensus algorithminclude Hyperledger Fabric.

Controller 13 is a processor that determines whether the goal conditionof the crowdfunding project is achieved and that controls deposit andtoken.

Controller 13 receives the goal condition of the crowdfunding fromterminal 40. Moreover, controller 13 receives a sign-up for funding fromterminals 50 and 51. Controller 13 determines whether the goal conditionof the crowdfunding is satisfied.

If determining that the goal condition is satisfied, controller 13stores, into the distributed ledger, token offering transaction data(corresponding to second transaction data) indicating that a tokenpredetermined for the service is offered to the participant.

For deposit control, controller 13 controls deposit offering and depositvalidity. More specifically, controller 13 offers a depositpredetermined for the service to the participant at a predeterminedtiming included in a period from when storing the sign-up transactiondata into the distributed ledger until when determining whether the goalcondition is satisfied. To offer the deposit to the participant,controller 13 stores, into the distributed ledger, deposit issuancetransaction data (corresponding to third transaction data) indicatingthat the deposit is offered. The predetermined timing may be a timing atwhich it is determined that a condition for offering the deposit to theparticipant (also referred to as a deposit issuance condition) issatisfied. To be more specific, to offer the deposit to the participant,controller 13 may determine beforehand whether the deposit issuancecondition is satisfied and, if so, offer the deposit to the participant.Here, the deposit offering from system 1 to the participant may also bephrased as “issuance”.

For example, the deposit issuance condition may be that a predeterminednumber of pieces of sign-up transaction data are received or that anincrease rate of the number of pieces of sign-up transaction datareceived exceeds a predetermined rate. Either of these examples isapplicable because, under such condition, a probability is relativelyhigh that the goal condition is determined as being satisfied.

Moreover, to control the deposit offering, controller 13 is also capableof controlling deposit offering from the user to another user. Morespecifically, after storing the deposit issuance transaction data intothe distributed ledger, controller 13 stores, into the distributedledger, deposit offering transaction data (corresponding to fourthtransaction data) indicating that the deposit is offered from the holderof the deposit to an offer recipient that receives the deposit.

To control the deposit validity refers to controlling whether to treatthe deposit as a valid or invalid deposit. Immediately after the depositissuance transaction data is stored into the distributed ledger, theissued deposit is managed as a valid deposit. Then, when the tokenoffering transaction data by which the token corresponding to thisdeposit is offered in response to the satisfaction of the goal conditionis stored into the distributed ledger, the deposit is managed as aninvalid deposit.

More specifically, if it is determined that the goal condition issatisfied or is to be unsatisfied, controller 13 invalidates thedeposit. To invalidate the deposit, controller 13 stores depositinvalidation transaction data (corresponding to fifth transaction data)indicating that the deposit is invalidated, into the distributed ledger.

If the goal condition is satisfied after the deposit is offered,controller 13 performs management so that the deposit is converted intoa true token. To be more specific, if determining that the goalcondition is satisfied after storing the deposit issuance transactiondata into the distributed ledger, controller 13 stores, into thedistributed ledger, token offering transaction data (corresponding tosixth transaction data) indicating that a token corresponding to thedeposit is offered to the holder of the deposit.

Here, if the goal condition is satisfied after the deposit is offered,controller 13 may provide a notification (more specifically, anotification encouraging a procedure for converting the deposit into thetrue token) to the holder of the deposit. To be more specific, ifdetermining that the goal condition is satisfied after storing thedeposit issuance transaction data into the distributed ledger,controller 13 may provide the notification to the holder of the deposit.

Assume that, after the deposit is offered, the goal condition isunsatisfied after the deposit is offered to another user (also referredto as a holder) different from the participant. In this case, controller13 may perform management so that the deposit of the holder is convertedinto the true token and also that a token corresponding to the depositof the holder is collected from the participant. Thus, controller 13 mayperform management so that the token corresponding to the deposit of theholder is offered from the participant to the holder. More specifically,if determining that the goal condition is unsatisfied after storing thedeposit issuance transaction data into the distributed ledger when theholder of the deposit is not the participant, controller 13 stores, intothe distributed ledger, token offering transaction data (correspondingto seventh transaction data) indicating that a token corresponding tothe deposit is offered from the participant to the holder.

Note that controller 13 may limit the number of times the deposit isoffered. More specifically, assume that the number of times the depositis offered exceeds a predetermined number of times when the depositoffering transaction data is to be stored into the distributed ledger.In this case, controller 13 may restrict storing of the deposit offeringtransaction data into the distributed ledger.

A part or a whole of the aforementioned processing of controller 13 maybe achieved by a smart contract implemented by executing a contract codestored in ledger memory 16. However, this is not intended to belimiting. For example, the deposit offering may be performed by a smartcontract that is executed in response to the storing of the firsttransaction data into the distributed ledger.

The following describes the transaction data of each kind.

FIG. 3 schematically illustrates deposit issuance transaction dataaccording to the present embodiment. The deposit issuance transactiondata illustrated in FIG. 3 is generated by servers 10A etc. for issuinga deposit.

The deposit issuance transaction data illustrated in FIG. 3 includes adeposit ID, an offer recipient ID, a deposit amount, an issuance dateand time, a remaining number of uses, and a signature.

The deposit ID is an identifier that uniquely identifies the depositissued through the deposit issuance transaction data.

The offer recipient ID is an identifier that uniquely identifies theuser who is offered the deposit issued through the deposit issuancetransaction data.

The deposit amount is information indicating a figure of the deposit (oran amount of the deposit) issued through the deposit issuancetransaction data.

The issuance date and time is information indicating a date and timewhen the deposit is issued through the deposit issuance transactiondata.

The remaining number of uses is information indicating the number oftimes the deposit issued through the deposit issuance transaction datais allowed to be used. The term “uses” refers to offering of the depositfor example. In this case, the remaining number of uses indicates thenumber of times the deposit is allowed to be offered. Here, theremaining number of uses is an example of limitation informationindicating a condition assigned to the deposit to be issued or offered.In addition to the remaining number of uses, the limitation informationmay include information indicating a ratio of the deposit to be furtheroffered with respect to the deposit offered through the deposit offeringtransaction data.

The signature is an electronic signature added by the device or personthat generates the deposit issuance transaction data.

The deposit issuance transaction data illustrated in FIG. 3 is used forissuing the deposit having the deposit ID “67g4” to user apa. The amountof the deposit issued is “1”, and the issuance date and time of thisdeposit is “2018. 10. 05 10:00:30”. The remaining number of uses of thedeposit is “3”. The signature is an electronic signature of server 10A,for example. Here, the user having the user ID “apa” is described as“user apa”. This manner of description is also adopted in the following.

The deposit issuance transaction data illustrated in FIG. 3 may be adata structure used in a service management system including a pluralityof servers each including a distributed ledger. The data structure mayinclude: identification information uniquely identifying a deposit thatis a temporary token predetermined for service; identificationinformation uniquely identifying an offer recipient that is offered thedeposit; and information indicating an amount of the deposit; and anelectronic signature of an issuer of the deposit.

Furthermore, the deposit issuance transaction data illustrated in FIG. 3may be a data structure recorded into a distributed ledger included ineach of a plurality of servers in a service management system. The datastructure may include: a first ID that is valid only in a periodpredetermined for service and that indicates a deposit as a temporarytoken offered to a participant that signs up for the service; an amountof the deposit; a use condition of the deposit; and a second ID thatindicates the participant. After recorded into the distributed ledger,the data structure may be used for offering the deposit to theparticipant.

FIG. 4 schematically illustrates deposit offering transaction dataaccording to the present embodiment. The deposit offering transactiondata is generated by servers 10A etc. for offering a deposit.

The deposit offering transaction data illustrated in FIG. 4 includes adeposit ID, an offer source ID, an offer recipient ID, a deposit amount,an offering date and time, a remaining number of uses, and a signature.

The deposit ID is an identifier that uniquely identifies the depositoffered through the deposit offering transaction data.

The offer source ID is an identifier that uniquely identifies the userwho is an offer source of the deposit offered through the depositoffering transaction data.

The offer recipient ID is an identifier that uniquely identifies theuser who is offered the deposit through the deposit offering transactiondata.

The deposit amount is information indicating a figure of the deposit (oran amount of the deposit) offered through the deposit offeringtransaction data.

The offering date and time is information indicating a date and timewhen the deposit is offered through the deposit offering transactiondata.

The remaining number of uses is information indicating the number oftimes the deposit offered through the deposit offering transaction datais allowed to be used. The remaining number of uses is an example oflimitation information indicating a condition assigned to the deposit tobe offered. The limitation information may include informationindicating a ratio of the deposit to be further offered after thedeposit is offered through this deposit offering transaction data.

The signature is an electronic signature added by the device or personthat generates the deposit offering transaction data.

The deposit offering transaction data illustrated in FIG. 4 is used foroffering the deposit having the deposit ID “67g4” from user apa to userapb. The amount of the deposit offered is “1”, and the offering date andtime of this deposit is “2018. 10. 14 15:00:00”. The remaining number ofuses of the deposit is “2”. The signature is an electronic signature ofthe offer source “apa”.

FIG. 5 schematically illustrates deposit invalidation transaction dataaccording to the present embodiment. The deposit invalidationillustrated in FIG. 5 is generated by servers 10A etc. for invalidatingthe deposit.

The deposit invalidation transaction data illustrated in FIG. 5 includesa deposit ID, an invalidation date and time, and a signature.

The deposit ID is an identifier that uniquely identifies the depositinvalidated through the deposit invalidation transaction data.

The invalidation date and time indicating a date and time when thedeposit is invalidated through the deposit invalidation transactiondata.

The signature is an electronic signature added by the device or personthat generates the deposit invalidation transaction data.

The deposit invalidation transaction data illustrated in FIG. 5 is usedfor invalidating the deposit having the deposit ID “67g4”. Theinvalidation date and time of this deposit is “2018. 10. 30 05:00:00”.The signature is an electronic signature of service 10A, for example.

FIG. 6 schematically illustrates token offering transaction dataaccording to the present embodiment. The token offering transaction dataillustrated in FIG. 6 is generated by servers 10A etc. for offering atoken.

The token offering transaction data illustrated in FIG. 6 includes atoken ID, an offer source ID, an offer recipient ID, a token amount, anoffering date and time, and a signature.

The token ID is an identifier that uniquely identifies the token offeredthrough the token offering transaction data.

The offer source ID is an identifier that uniquely identifies the userwho is an offer source of the token offered through the token offeringtransaction data.

The offer recipient ID is an identifier that uniquely identifies theuser who is an offer recipient of the token offered through the tokenoffering transaction data.

The token amount is information indicating a figure of the token (or anamount of the token) offered through the token offering transactiondata.

The offering date and time is information indicating a date and timewhen the token is offered through the token offering transaction data.

The signature is an electronic signature added by the device or personthat generates the token offering transaction data.

The token offering transaction data illustrated in FIG. 6 is used foroffering the token having the token ID “10067g4” from user apa to userusx. The amount of the token offered is “1”, and the offering date andtime of this token is “2018. 10. 30 05:00:00”. The signature is anelectronic signature of service 10A, for example.

The following describes operations performed by system 1 and servers 10Aetc. having the configurations described above.

FIG. 7 is a flowchart illustrating a first example of processingperformed by servers 10A etc. according to the present embodiment.Assume that controller 13 has already obtained the goal condition fromterminal 40 of manager U1 at the start of this flowchart illustrated inFIG. 7.

As illustrated in FIG. 7, processor 11 determines whether sign-uptransaction data is received from terminal 50 of participant U2, in StepS101. If the sign-up transaction data is received (Yes in Step S101),processor 11 proceeds to Step S102. Otherwise (No in Step S101),processor 11 proceeds to Step S103.

In Step S102, processor 11 stores the sign-up transaction data receivedin Step S101 into the distributed ledger by providing this sign-uptransaction data to ledger manager 12. Moreover, processor 11 transmitsthe sign-up transaction data to other servers 10B etc. so that thesign-up transaction data is stored into all the distributed ledgers ofservers 10A etc.

In Step S103, controller 13 determines whether the deposit issuancecondition is satisfied. If determining that the deposit issuancecondition is satisfied (Yes in Step S103), controller 13 proceeds toStep S104. Otherwise (No in Step S103), controller 13 proceeds to StepS106.

In Step S104, controller 13 generates deposit offering transaction datafor issuing a deposit.

In Step S105, controller 13 stores the deposit offering transaction datagenerated in Step S104 into the distributed ledger by providing thisdeposit offering transaction data to ledger manager 12. Moreover,controller 13 transmits the deposit offering transaction data to otherservers 10B etc. so that the deposit offering transaction data is storedinto all the distributed ledgers of servers 10A etc. After this, theoffered deposit can be offered to another user. Processing performed foroffering the deposit to another user is described later.

In Step S106, controller 13 determines whether the solicitation periodis expired. Whether the solicitation period is expired is determined bydetermining whether a predetermined solicitation expiry date is reached.If determining that the solicitation period is expired (Yes in StepS106), controller 13 proceeds to Step S107. Otherwise (No in Step S106),controller 13 proceeds to Step S101.

In Step S107, controller 13 notifies participant U3 for instance, ormore specifically terminal 50 for instance, that the solicitation periodis expired. Note that Step S107 may not be executed.

In Step S108, controller 13 determines whether the goal condition of thecrowdfunding project is satisfied. If determining that the goalcondition is satisfied (Yes in Step S108), controller 13 proceeds toStep S109. Otherwise (No in Step S108), controller 13 proceeds to StepS121.

In Step S109, controller 13 notifies participant U3 for instance, ormore specifically terminal 50 for instance, that the goal condition issatisfied. Note that Step S109 may not be executed.

In Step S110, controller 13 generates invalidation transaction data forinvalidating the deposit.

In Step S111, controller 13 stores the invalidation transaction datagenerated in Step S110 into the distributed ledger by providing thisinvalidation transaction data to ledger manager 12. Moreover, controller13 transmits the invalidation transaction data to other servers 10B etc.so that the invalidation transaction data is stored into all thedistributed ledgers of servers 10A etc.

In Step S112, controller 13 generates token offering transaction datafor offering a token from the manager to the holder of the deposit. Inthe generated token offering transaction data, the amount of tokenoffered corresponds to the amount of deposit held by the holder.

In Step S113, controller 13 stores the token offering transaction datagenerated in Step S112 into the distributed ledger by providing thistoken offering transaction data to ledger manager 12. Moreover,controller 13 transmits the token offering transaction data to otherservers 10B etc. so that the token offering transaction data is storedinto all the distributed ledgers of servers 10A etc.

In Step S121, controller 13 notifies participant U3 for instance, ormore specifically terminal 50 for instance, that the goal condition isunsatisfied. Note that Step S121 may not be executed.

In Step S122, controller 13 generates invalidation transaction data forinvalidating the deposit.

In Step S123, controller 13 stores the invalidation transaction datagenerated in Step S122 into the distributed ledger by providing thisinvalidation transaction data to ledger manager 12. Moreover, controller13 transmits the invalidation transaction data to other servers 10B etc.so that the invalidation transaction data is stored into all thedistributed ledgers of servers 10A etc.

In Step S124, controller 13 generates token offering transaction datafor offering the token from the participant to an offer recipient. Inthe generated token offering transaction data, the amount of tokenoffered corresponds to the amount of deposit held by the offerrecipient.

In Step S125, controller 13 stores the token offering transaction datagenerated in Step S124 into the distributed ledger by providing thistoken offering transaction data to ledger manager 12. Moreover,controller 13 transmits the token offering transaction data to otherservers 10B etc. so that the token offering transaction data is storedinto all the distributed ledgers of servers 10A etc.

After Step S113 or S125, a series of steps illustrated in FIG. 7 ends.

FIG. 8 is a flowchart illustrating a second example of processingperformed by server 10A according to the present embodiment.

The processing illustrated in FIG. 8 is performed concurrently with theprocessing illustrated in FIG. 7, in a period from when the deposit isissued (Step S105 in FIG. 7) and until when the deposit is invalidated(Step S111 or S123 in FIG. 7).

In Step S201, processor 11 determines whether deposit offeringtransaction data is received from terminal 50 of participant U2 forinstance. If receiving the deposit offering transaction data (Yes inStep S201), processor 11 proceeds to Step S202. Otherwise (No in StepS201), processor 11 executes Step S201 again. More specifically,processor 11 waits at Step S201 until the deposit offering transactiondata is received.

In Step S202, controller 13 determines whether the remaining number ofuses is at least one, by reference to the remaining number of usesincluded in the deposit offering transaction data received in Step S201.If determining that the remaining number of uses is at least one (Yes inStep S202), controller 13 proceeds to Step S203. Otherwise (No in StepS202), controller 13 proceeds to Step S211.

In Step S203, processor 11 stores the deposit offering transaction datareceived in Step S201 into the distributed ledger by providing thisdeposit offering transaction data to ledger manager 12. Moreover,processor 11 transmits the deposit offering transaction data to otherservers 10B etc. so that the deposit offering transaction data is storedinto all the distributed ledgers of servers 10A etc.

In Step S204, controller 13 decrements by one the remaining number ofuses of the deposit related to the deposit offering transaction datareceived in Step S201. After executing Step S204, controller 13 proceedsto Step S201.

In Step S211, controller 13 notifies the offer source that the number ofuses exceeds the limit. Here, controller 13 may store, into thedistributed ledger, that the number of uses exceeds the limit. Afterexecuting Step S211, controller 13 proceeds to Step S201.

If the limit for the number of uses of the deposit is not managed, StepsS202, S204, and S211 are not to be executed.

Next, system-wide processing of system 1 is described.

FIG. 9 is a sequence that corresponds to FIG. 7 and illustratessystem-wide processing of system 1. FIG. 9 illustrates the system-wideprocessing of system 1 performed when the goal condition is satisfied.Note that the same processes as in the flowchart of FIG. 7 are assignedthe same step numbers as in FIG. 7 and are not described in detail.

Terminal 40 of manager U1 generates a goal condition and transmits thegoal condition to servers 10A etc. beforehand (Step S301). The goalcondition includes a solicitation period and a goal amount, for example.Server 10A receives the transmitted goal condition, which is sharedamong servers 10A etc. (Step S100).

In Step S311, terminal 50 generates sign-up transaction data andtransmits the generated sign-up transaction data to servers 10A etc. Atthis time, terminal 50 may transmit the generated sign-up transactiondata to one or at least two of servers 10A etc.

Servers 10A etc. receive the sign-up transaction data transmitted andstore this sign-up transaction data into the distributed ledgers (StepsS101 and S102). If determining that the deposit issuance condition issatisfied, servers 10A etc. generate deposit offering transaction datafor issuing a deposit to participant U3 owning terminal 51 that is thetransmission source of the sign-up transaction data, and store thegenerated deposit offering transaction data into the distributed ledgers(Steps S103 to S105). Upon expiry of the solicitation period, servers10A etc. transmit a notification about the expiry of the solicitationperiod (Steps S106 and S107).

If the goal condition is satisfied, servers 10A etc. generateinvalidation transaction data for invalidating the deposit alreadyissued, and store the generated invalidation transaction data into thedistributed ledgers (Steps S110 and S111).

Moreover, servers 10A etc. generate token offering transaction data foroffering a token to the holder of the deposit, and store the generatedtoken offering transaction data into the distributed ledgers (Steps S112and S113).

Variation 1 of Embodiment

The following describes another configuration of the service managementsystem, according to the present variation of the embodiment describedabove.

FIG. 10 is a schematic block diagram illustrating a configuration ofsystem 2 according to the present variation.

As illustrated in FIG. 10, system 2 includes servers 10A, 10B, and 10C,and terminals 40, 50, and 51. These devices included in system 2 arecommunicably connected to each other via network N. Network N may useany kind of communication line or network. Examples include the Internetand a mobile phone carrier network.

In particular, servers 10A, 10B, and 10C of system 2 are connected toeach other via network N. Server 10A is connected to terminal 51. Server10B is connected to terminal 50. Server 10C is connected to terminal 40.

Such configuration may be used for system 2 run by a plurality of groupsthat have respective managed servers connected to each other via networkN. For example, server 10A and terminal 51 belong to group A, server 10Band terminal 50 belong to group B, and server 10C and terminal 40 belongto group C.

Operations performed by servers 10A etc. and terminals 40 etc. are thesame as those described in the embodiment above, and thus are omittedfrom the description.

Variation 2 of Embodiment

The following describes another configuration of the service managementsystem, according to the present variation of the embodiment describedabove.

FIG. 11 is a schematic block diagram illustrating a configuration ofsystem 3 according to the present variation.

As illustrated in FIG. 11, system 3 includes server 10D and terminals40, 50, and 51. The devices included in system 3 are communicablyconnected to each other via network N. Network N may use any kind ofcommunication line or network. Examples include the Internet and amobile phone carrier network.

In particular, server 10D and terminals 50 and 51 of system 3 areconnected to each other via network N. Server 10D is connected toterminal 40. In this case, terminals 50 and 51 operate as servers 10Aetc. according to the embodiment described above.

Such configuration may be used for system 3 run by at least one groupand at least one individual that have respective managed servers orterminals connected to each other via network N. For example, server 10Dand terminal 40 belong to group D. System 3 is run by group D andindividual participants U2 and U3.

Operations performed by server 10D and terminals 40 etc. are the same asthose described in the embodiment above, and thus are omitted from thedescription.

Variation 3 of Embodiment

FIG. 12 is a flowchart illustrating processing performed by a serveraccording to the present variation. The flowchart of FIG. 12 is acontrol method executed by one of a plurality of servers included in aservice management system, each of the plurality of servers including adistributed ledger.

The server receives first transaction data related to a sign-up forservice and stores the first transaction data received into thedistributed ledger included in each of the plurality of servers (StepS401). The service offers, if a goal condition predetermined for thisservice is satisfied, a token to a participant that is a user who signsup for the service.

If determining that the goal condition is satisfied (Yes in Step S403),the server stores, into the distributed ledger, second transaction dataindicating that the user is offered a token predetermined for theservice (Step S404).

The server stores third transaction data into the distributed ledger ata predetermined timing included in a period from when storing the firsttransaction data into the distributed ledger until when determiningwhether the goal condition is satisfied (Step S402). Here, the thirdtransaction data indicates that the user is offered a deposit that is atemporary token predetermined for the service.

This enables the service management system to enhance power consumptionefficiency of the system.

FIG. 13 is a schematic block diagram illustrating a configuration of theserver according to the present variation.

As illustrated in FIG. 13, the service management system includes aplurality of servers each of which includes a distributed ledger. Server60A among the plurality of servers includes processor 61 and controller63.

Processor 61 receives first transaction data related to a sign-up forservice and stores the first transaction data received into thedistributed ledger included in each of the plurality of servers. Theservice offers, if a goal condition predetermined for this service issatisfied, a token to a participant that is a user who signs up for theservice.

If determining that the goal condition is satisfied, controller 63stores, into the distributed ledger, second transaction data indicatingthat the user is offered a token predetermined for the service.Controller 63 stores third transaction data into the distributed ledgerat a predetermined timing included in a period from when storing thefirst transaction data into the distributed ledger until whendetermining whether the goal condition is satisfied. Here, the thirdtransaction data indicates that the user is offered a deposit that is atemporary token predetermined for the service.

This enables the service management system to enhance power consumptionefficiency of the system.

Complementary Remarks

A blockchain according to the embodiment above and variations iscomplementally described.

FIG. 14 illustrates a data structure of a blockchain.

A blockchain includes blocks, each being a unit of recording, and formsa chain by linking the blocks together. Each of the blocks includes aplurality of pieces of transaction data and a hash value of animmediately preceding block. To be more specific, block B2 includes ahash value of block B1 that is the immediately preceding block. Then, ahash value calculated from the plurality of pieces of transaction dataincluded in block B2 and the hash value of block B1 is contained as thehash value of block B2 in block B3. In this way, blocks contain theinformation of the preceding block as the hash value, forming a chain.This effectively prevents the recorded transaction data fromfalsification.

If the transaction data in the past is modified, the hash value of theblock is different from the value before the modification. To make thefalsified block appear correct, all the subsequent blocks need to bealtered. Realistically speaking, this is extremely difficult. Suchcharacteristics of blockchains assure resistance to falsification.

FIG. 15 illustrates a data structure of transaction data.

Transaction data illustrated in FIG. 15 includes transaction data boy P1and electronic signature P2. Transaction data body P1 is a data bodyincluded in the transaction data. Electronic signature P2 is signedusing a signing key of a creator of the transaction data. Morespecifically, electronic signature P2 is generated through encryptionusing a private key of the creator.

It is substantially impossible for the transaction data includingelectronic signature P2 to be falsified. This prevents the transactiondata body from falsification.

As described above, the system offers, to the user, the deposit as thetemporary token corresponding to a token that is value information to beoffered in the future, in a period before the goal condition isachieved. The deposit may be managed in the distributed ledger to beused in the same or similar manner as the token is. This enables thesystem to offer the value information to the user in the period beforethe goal condition is achieved, thereby enhancing power consumptionefficiency of the system. Thus, the control method according to thepresent disclosure is capable of enhancing the power consumptionefficiency of the system.

Moreover, it is substantially impossible for the transaction data storedin the distributed ledger to be falsified. Thus, the managementinformation related to the deposit offering is appropriately managed bythe system. If the management information were to be falsified, this maycause inappropriate distribution of the value information, such asdeposit or token. However, the control method according to the aspect ofthe present disclosure stores the management information into thedistributed ledger, so that falsification is substantially impossible.Hence, the control method according to the aspect of the presentdisclosure also has an advantageous effect of appropriately managing thedistribution of the value information, such as deposit or token.

Moreover, the system is further capable of offering the deposit to theoffer recipient and thereby distributing among users the valueinformation offered to the participant. Such distribution of the valueinformation enables the system to further enhance the power consumptionefficiency. Hence, the control method according to the aspect of thepresent disclosure is capable of further enhancing the power consumptionefficiency of the system.

Furthermore, the system is capable of invalidating the deposit if thegoal condition is unsatisfied, and thereby appropriately controlling thevalidity of the deposit. Hence, the control method according to thepresent disclosure is capable of appropriately managing the distributionof the value information as well as further enhancing the powerconsumption efficiency of the system.

Moreover, the system is capable of offering the token corresponding tothe deposit if the goal condition is satisfied, and thus also performingmanagement so that the deposit is converted into the token after thegoal condition is satisfied. Hence, the control method according to thepresent disclosure is capable of further appropriately managing thedistribution of the value information as well as further enhancing thepower consumption efficiency of the system.

Furthermore, the system is capable of providing a notification that thegoal condition is satisfied, and thereby encouraging action (that is,exchange) for converting the deposit into the token after the goalcondition is satisfied. Hence, the control method according to thepresent disclosure is capable of further appropriately managing thedistribution of the value information as well as further enhancing thepower consumption efficiency of the system.

Moreover, the system is capable of performing, if the goal condition issatisfied, management so that the token converted from the deposit ownedby the holder different from the participant appears to be offered fromthe participant. If the deposit held by the holder were to simplydisappear, this may cause inappropriate distribution of the valueinformation. Hence, the control method according to the presentdisclosure is capable of further appropriately managing the distributionof the value information as well as further enhancing the powerconsumption efficiency of the system.

Furthermore, the system is capable of performing management so that thenumber of times the deposit is offered does not exceed the predeterminednumber of times. This management limits a range of the deposit offeringbecause the deposit is allowed to be used as a token only in a periodbefore the goal condition is satisfied. Hence, the control methodaccording to the present disclosure is capable of further appropriatelymanaging the distribution of the value information as well as furtherenhancing the power consumption efficiency of the system.

Moreover, the system performs the deposit offering early and safelywithout any intervention of another person or another system. Hence, thecontrol method according to the present disclosure is capable ofperforming the processing early and safely as well as enhancing thepower consumption efficiency of the system.

Furthermore, the system stores the distributed ledger through theexecution of the consensus algorithm. Hence, the control methodaccording to the present disclosure more easily enables enhancement ofthe power consumption efficiency of the system by the execution of theconsensus algorithm.

Moreover, in the above embodiment, the respective structural componentsmay be implemented as dedicated hardware or may be realized by executinga software program suited to the respective structural components.Alternatively, the respective structural components may be implementedby a program executor such as a CPU or a processor reading out andexecuting the software program recorded in a recording medium such as ahard disk or a semiconductor memory. Here, the software for implementingthe content management system and so forth in the above embodiment is aprogram such as that described below.

Specifically, the above program is program that causes a computer toexecute a control method executed by one of a plurality of serversincluded in a service management system, each of the plurality ofservers including a distributed ledger, the control method. The controlmethod includes: receiving first transaction data that is transactiondata related to a sign-up for service and storing the first transactiondata received into the distributed ledger included in each of theplurality of servers, the service offering, if a goal conditionpredetermined for the service is satisfied, a token to a participantthat is a user who signs up for the service; storing, into thedistributed ledger, second transaction data that is transaction dataindicating that the user is offered the token predetermined for theservice, if it is determined that the goal condition is satisfied; andstoring, into the distributed ledger, third transaction data that istransaction data indicating that the user is offered a deposit that is atemporary token predetermined for the service, at a predetermined timingincluded in a period from the storing of the first transaction data intothe distributed ledger until when determination of whether the goalcondition is satisfied is performed.

Although a fund management system according to one or more aspects hasbeen described above based on exemplary embodiments, the presentdisclosure is not limited to the foregoing embodiments. Forms achievedby making various modifications to the above embodiments that can beconceived by those skilled in the art, as well forms achieved bycombining structural components in different embodiments, so long asthey do not materially depart from the spirit of the present disclosure,may be included in the one or more aspects.

INDUSTRIAL APPLICABILITY

The present disclosure is applicable to a service management system thatmanages service for offering a token to a participant.

1. A control method executed by one of a plurality of servers includedin a service management system, each of the plurality of serversincluding a distributed ledger, the control method comprising: receivingfirst transaction data that is transaction data related to a sign-up forservice and storing the first transaction data received into thedistributed ledger included in each of the plurality of servers, theservice offering, if a goal condition predetermined for the service issatisfied, a token to a participant that is a user who signs up for theservice; storing, into the distributed ledger, second transaction datathat is transaction data indicating that the user is offered the tokenpredetermined for the service, if it is determined that the goalcondition is satisfied; and storing, into the distributed ledger, thirdtransaction data that is transaction data indicating that the user isoffered a deposit that is a temporary token predetermined for theservice, at a predetermined timing included in a period from the storingof the first transaction data into the distributed ledger until whendetermination of whether the goal condition is satisfied is performed.2. The control method according to claim 1, further comprising: afterthe storing of the third transaction data into the distributed ledger,storing, into the distributed ledger, fourth transaction data that istransaction data indicating that the deposit is offered from a holder ofthe deposit to an offer recipient that receives the deposit.
 3. Thecontrol method according to claim 1, further comprising: if it isdetermined that the goal condition is satisfied or if it is determinedthat the goal condition is unsatisfied, after the storing of the thirdtransaction data into the distributed ledger, storing, into thedistributed ledger, fifth transaction data that is transaction data forinvalidating the deposit.
 4. The control method according to claim 1,further comprising: if it is determined that the goal condition issatisfied after the storing of the third transaction data into thedistributed ledger, storing, into the distributed ledger, sixthtransaction data that is transaction data for offering a tokencorresponding to the deposit to a holder of the deposit.
 5. The controlmethod according to claim 1, further comprising: if it is determinedthat the goal condition is satisfied after the storing of the thirdtransaction data into the distributed ledger, notifying a holder of thedeposit that the goal condition is satisfied.
 6. The control methodaccording to claim 3, further comprising: if a holder of the deposit isnot the participant and it is determined that the goal condition isunsatisfied after the storing of the third transaction data into thedistributed ledger, storing, into the distributed ledger, seventhtransaction data that is transaction data for offering a tokencorresponding to the deposit from the participant to the holder.
 7. Thecontrol method according to claim 2, wherein the storing of the fourthtransaction data into the distributed ledger includes limiting thestoring of the fourth transaction data into the distributed ledger if atotal number of times the deposit is offered exceeds a predeterminedtotal number of times.
 8. The control method according to claim 1,wherein the storing of the third transaction data into the distributedledger includes storing of the third transaction data into thedistributed ledger through a smart contract that is executed in responseto the storing of the first transaction data into the distributedledger.
 9. The control method according to claim 1, wherein the storingof the transaction data into the distributed ledger included in each ofthe plurality of servers includes storing the transaction data into thedistributed ledger through execution of a consensus algorithm by each ofthe plurality of servers.
 10. A data structure used by a servicemanagement system including a plurality of servers each of whichincludes a distributed ledger, the data structure comprising:identification information that uniquely identifies a deposit that is atemporary token predetermined for service; identification informationthat uniquely identifies an offer recipient that receives the deposit;information that indicates an amount of the deposit; and an electronicsignature of an issuer of the deposit.
 11. A server among a plurality ofservers included in a service management system, each of the pluralityof servers including a distributed ledger, the server comprising: aprocessor; and a controller, wherein the processor receives firsttransaction data related to a sign-up for service and stores the firsttransaction data received into the distributed ledger included in eachof the plurality of servers, the service offers, if a goal conditionpredetermined for the service is satisfied, a token to a participantthat is a user who signs up for the service, and the controller: stores,into the distributed ledger, second transaction data indicating that theuser is offered the token predetermined for the service, if determiningthat the goal condition is satisfied, and stores, into the distributedledger, third transaction data indicating that the user is offered adeposit that is a temporary token predetermined for the service, at apredetermined timing included in a period from when storing the firsttransaction data into the distributed ledger until when determiningwhether the goal condition is satisfied.
 12. A non-transitorycomputer-readable recording medium having recorded thereon a program forcausing a computer to execute the control method according to claim 1.13. A data structure that is recorded into a distributed ledger includedin each of a plurality of servers in a service management system, thedata structure comprising: a first ID that is valid only in a periodpredetermined for service and that indicates a deposit as a temporarytoken offered to a participant that signs up for the service; an amountof the deposit; a use condition of the deposit; and a second ID thatindicates the participant, wherein after being recorded into thedistributed ledger, the data structure is used for offering the depositto the participant.